I looked through ../cachew.

cachew handles this differently because it is mirror-backed, not just response-cache-backed:

- It detects command=ls-refs in RequestIsClone, but only to avoid counting v2 discovery as a clone. See ../cachew/internal/strategy/git/
  repocounts.go:68.

- The detection is bounded and gzip-aware: reads up to 64 KiB, checks first 256 bytes for command=ls-refs, then replays the body for downstream. See ../
  cachew/internal/strategy/git/repocounts.go:80.

- During initial mirror creation, cachew spools POST /git-upload-pack responses by request-body hash, so v2 ls-refs and fetch do not collide. It does not specially bypass
  ls-refs spooling. See ../cachew/internal/strategy/git/git.go:411 and ../cachew/internal/strategy/git/git.go:470.

- Once the mirror is ready, it serves upload-pack through local git http-backend, including v2 ls-refs. See ../cachew/internal/strategy/git/
  backend.go:84.

- Its freshness bypass is only explicit for GET info/refs: if refs are stale, forward upstream and fetch in background. See ../cachew/internal/strategy/
  git/git.go:367.

So for our repo, the persistent-cache bypass for command=ls-refs is still the right equivalent. cachew can safely serve ls-refs from a mirror/spool because those are either
local Git state or temporary in-flight dedupe; our current content-cache stores raw responses for 24h, so caching ls-refs there would risk stale ref discovery.